home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 2765 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.8 KB
  1. Path: news.ccs.queensu.ca!news
  2. From: dmurdoch@mast.queensu.ca (Duncan Murdoch)
  3. Newsgroups: comp.lang.c++,comp.lang.pascal.delphi.misc
  4. Subject: Re: C++ with Zapp vs. Delphi
  5. Date: Fri, 19 Jan 1996 13:10:10 GMT
  6. Organization: Queen's University, Kingston
  7. Message-ID: <30ff9519.1799465@130.15.126.54>
  8. References: <4coar6$d4n@sun4.bham.ac.uk> <4coip7$69s@news1.usa.pipeline.com> <DBk8wg2yqjbB083yn@iaccess.za> <4d7pmb$48c8@tigger.cc.uic.edu> <4dk38h$gdr@merlin.delphi.com> <4dksp1$3d6c@tigger.cc.uic.edu> <30fe666e.3349285@130.15.126.54> <4dmjt8$6sv@crc-news.doc.ca>
  9. NNTP-Posting-Host: free1-slip213.tele.queensu.ca
  10. X-Newsreader: Forte Agent .99c/16.141
  11.  
  12. Slobodan Celenkovic <slobodan@cs.unh.edu> wrote:
  13.  
  14. >dmurdoch@mast.queensu.ca (Duncan Murdoch) wrote:
  15.  
  16. >>The way this is done in Delphi is to create a descendant of the
  17. >>SortedList that overrides the compare method.  Instead of forcing you
  18. >>to only put SortedObjects in the list, this allows you to put anything
  19. >>there, even non-objects like integers or strings or empty holes, if
  20. >>that suits your fancy.
  21.  
  22. >- Each items defines HOW it is compared to other items, and CONTROLS to
  23. >  which items it may be compared. Again makes sense - the item classes
  24. >  should control what they can be compared with, i.e. which comparisons
  25. >  make sense.
  26.  
  27. No, that's nonsense.  Often I want to have a multiply indexed
  28. database.  I can do the same thing with lists:  have each item in
  29. several different lists, so that I can do a fast search on name, or
  30. address, or telephone area code, or whatever.  *The item shouldn't
  31. handle the compare, the list should.*
  32.  
  33. >
  34. >No multiple-inheritance, no operator overloading -> Delphi:
  35. >===========================================================
  36. >
  37. >We can't use the abstract item so:
  38. >
  39. >class IntItem(some other class);      <- data classes
  40. >class StringItem(some other class);
  41. >class MoneyItem(some other class);
  42.  
  43. Why on earth would you bother to declare those things as classes?  If
  44. you're writing a descendant of the list class, you just make sure it
  45. can handle the data directly, without the overhead of putting it in a
  46. class.
  47.  
  48. >Consequences:
  49. >
  50. >- A list class for each item class, hence we end up with twice as many
  51. >  classes. Furthermore we are placing some (little) item specific code   
  52. >  into the list class; item specific code really belongs in the item
  53. >  class!
  54.  
  55. No, you end up with the same number of classes.  *You* need to write a
  56. separate class for each item to be put into the list.  *I* need to
  57. write a separate class for each kind of list.  I don't need to put
  58. sorting information into items; sorting is what the list does.
  59.  
  60. >- A list may only contain a single type of item. The MI solution's list
  61. >  can store more than one type of item provided that the appropriate
  62. >  comparison functions are defined (so a list contain strings, integeres
  63. >  and money)
  64.  
  65. Why do you think this?  The list can contain *anything*.  If I did
  66. decide to put multiple kinds of items into the list, I would probably
  67. put them in some kind of common container, but I don't need to.  I can
  68. just do a run-time check of the type of each item.  This would require
  69. them to be classes, but it wouldn't require them to know they're in
  70. the list.
  71.  
  72. >Finally to put the discussion into perspective. #1 is obviously the best 
  73. >and most elegant solution. Yet even without MI (Delphi) it is doable. So 
  74. >the price we pay in Delphi is that the solution is not quite as elegant.
  75.  
  76. No, it's not obvious to me.  You still didn't tell me how to put the
  77. same item into different lists using different sort keys.  
  78.  
  79. > So Pascal is well suited for clients (GUI), C++ for servers. 
  80.  
  81. No, I don't think there is really that much difference.  Everything
  82. I've said above about the "right" way to implement a list would also
  83. be the "right" way to do it in C++.  I suspect MI has been used for
  84. this just because C++ has MI, not because it makes sense to implement
  85. a list that way.
  86.  
  87. Duncan Murdoch
  88.